Some changes occurred in compiler/rustc_codegen_ssa

cc @WaffleLapkin

I expect that this PR lands on the version 1.92 cycle (I chose extensions with relatively low risk factors) but happy if it could be merged in the version 1.91 cycle.

LGTM, these are all officially ratified RISC-V extensions.

@rfcbot merge

Team member @Amanieu has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se
• @nikomatsakis
• @scottmcm
• @the8472
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.

We'll need a PR to the Reference submitted and accepted ahead of this being merged.

@rfcbot reviewed

cc @rust-lang/lang-docs @RalfJung

Consideration: Feature Naming (for std_detect)

The only initial intent of riscv_ratified_v2 (which feels a bit blunt) was to avoid crashing with existing riscv_ratified¹ and later noticed that x86 uses various feature names on stabilization.

I considered the similar after the initial submission but didn't for several reasons:

1. Many extensions to be stabilized are general purpose (even some of them are split from an early version of the I base ISA) and clear distinction will confuse the users between plain riscv_ratified (it's just a collection of extensions where runtime detection of them is stabilized in Rust 1.78.0 and contains rich extensions like scalar cryptography).
2. Considering future extensions to be stabilized in Rust and the history (some RISC-V extensions are split from others and semantic naming may not work in the near future), either of them seems inevitable:
   1. Using the extension name itself or similar or
   2. Using blunt version schemes like in this PR.

After consideration, I prefer blunt naming scheme (pure versioning regardless of the category) for runtime detection of RISC-V extensions.

Consideration: Deferring to Version 1.92 Cycle may Have its Benefit

Although I'll rush for the version 1.91 cycle if possible, I have to say that deferring this might be an option.

I'm talking about #145071, which raises the minimum LLVM version to 20. After this PR is merged, I think we can safely introduce the Zacas extension without riscv_ratified_v3 (I excluded Zacas from this PR because of this minimum LLVM version issue).

So, if we don't make it to the version 1.91 cycle, waiting for #145071 might be an option.

@traviscross Thanks for pointing out!

I opened the PR rust-lang/reference#1987 to align with this.

No ABI issues will not occur unless floating point registers are involved. But for integer-only vector ones, we'll be stabilizing in another time.

I can't parse this comment, too many negations.^^ Integer vector registers can also cause ABI issues, if they are sometimes used by the calling convention but not always available.

I can't parse this comment, too many negations.

Double negation in the first sentence is intended. Still, there are too much negations after that, I have to admit. I'll try if I can improve this.

Integer vector registers can also cause ABI issues, if they are sometimes used by the calling convention but not always available.

Did I miss something?

In the standard ABI and normal cases, all vector registers are function-local temporaries.
If variant calling convention is used in a function, standard ABI defines how to communicate between the function itself (callee) and the caller using vector registers but nothing more (and all preserved vector registers are callee-saved). I can't find a case where vector integer ops can cause ABI issues.

Double negation in the first sentence is intended

Please avoid that, it makes things very hard to read and very easy to misunderstand.

"No ABI issues will not occur" means that ABI issues will occur which I hope is not what you meant.

If variant calling convention is used in a function, standard ABI defines how to communicate between the function itself (callee) and the caller using vector registers but nothing more (and all preserved vector registers are callee-saved). I can't find a case where vector integer ops can cause ABI issues.

I don't know what the "variant calling convention" is. I also don't know the specifics of any of these extensions, or really much about RISC-V at all. I am just replying to a comment that seemed to somehow say that "float registers could cause a problem but integers cannot", which doesn't make sense to me. Any extensions that makes more registers available could become a problem if arguments start to be passed in those registers. If there are no new registers (nor other new machine state) or the registers are never used for arguments, then great, we have no problem.

The comment seems to say that something with integer vectors should be stabilized "another time", so I hope we are fine. But I am not sure since I have a hard time parsing that sentence. It first talks about floats and then about ints, but ints happen another time -- so are floats affected now in this PR or not?

Sorry for being so nitpicky here, but I'd rather not risk introducing some soundness issue over a misunderstanding caused by a language barrier. Better to double-check. :)

Please avoid that, it makes things very hard to read and very easy to misunderstand.

Understood. I think I need to rewrite the entire paragraph.

I am just replying to a comment that seemed to somehow say that "float registers could cause a problem but integers cannot", which doesn't make sense to me.

The reason behind "floating point registers cause an ABI issue" is something like #[target_feature(enable = "f")] can change how to pass floating point numbers.

However, passing something through vector registers require the callee to enable variant calling conventions (e.g. vector intrinsics in future core::arch would enable variant calling convention) and we can only pass vector data (unavailable on non-vector environment).
On all other cases, vector registers are never used to pass information between functions.

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Rebased and made minor adjustments to the commit message (no changes in the code).

@RalfJung I think this is at least better than before.

• Not vector-related (floating point and integer).
  While integer vector subsets should not cause any ABI issues (as they don't use ABI-dependent floating point registers), we need to discuss before stabilizing them.

EDIT: Minor correction is made after initial correction.

Sorry for being so nitpicky here, but I'd rather not risk introducing some soundness issue over a misunderstanding caused by a language barrier. Better to double-check. :)

I completely agree that. We'd better to discuss it.

Thanks! I'm still confused about what's happening with integer vectors, but since they are not being stabilized here we don't have to resolve that now.